| DevOps落地 | 您所在的位置：网站首页 › devops 工具链 › DevOps落地 |
DevOps落地
|
工作回顾、一图胜千言
一图胜千言： 如有人问，在XX公司做什么，做出了什么成绩？工作确实有些“杂”，回答这个问题，很有必要回顾、系统思考、体系总结一下； 总结就是，在DevOps领域，主要是 CICD、容器平台、网络互联、工具链、应用容器环境设计 5个技术方面，做出了一点成果，支持公司车联网业务发展； 业务、行业的一点思考用confluence画了一张图，公司的业务、技术都可以从这张图找到根源： 车联网，即把车、车主、车厂、数字服务商互联，如图所示，再此之上，承载各种业务场景。 典型的一个车企例子–特斯拉；而国内各大车企，或多或少，都想成为“特斯拉”。面临特斯拉这类互联网型车企的巨大挑战，网联化、数字化、智能化，车企的转型升级任务必要且紧迫； 三大ToB业务公司的业务就是紧紧围绕车联网，围绕国内各大车企在，网联化、数字化、智能化、电动化，的转型需求。 公司业务围绕这张图开展的，客户是车企，提供技术服务。 根据公司定位；可总结为车企提供三大类技术服务： 平台建设，围绕 TSP平台建设，解决车、车主、车企连接问题；生态聚合，打通 车主-TSP系统-数字服务提供商 链路；数据增值，用大数据等技术助力车企拓展为数据企业；图中当然还有其他业务，目前公司没有涉及，比如， 车机、Tbox车载硬件；导航、支付等用车服务；买车等营销服务；保养、4S等养车服务；…等 困难、挑战2018年，公司的技术栈为： 应用层，使用 Java/SpringCloud、Springboot/Nodejs、使用了微服务。 容器层，使用docker、docker-compose方式，没有使用kubernetes，没有容器平台。 网络层，没有明确规划，办公网络、云VPC网络、项目环境网络比较乱。 云平台层，共用一个阿里云，使用、权限比较混乱。 困难一：三低，效率低、士气低、质量低 效率低 举些例子，这些例子是2018年初，我们遇到的效率问题。 活动效率问题举例构建1. Jenkinsfile 维护工作量大、易出错。微服务化后，多个项目都几十上百个Git代码，每个Git一个Jenkinsfile，改一个环境地址要改几十上百个部署1. 微服务应用部署名称问题。不统一，易混乱；应用。配置1. 应用配置文件多问题。每次发布哪些配置更改过？日志1. 看应用日志问题。开发问，去哪里看日志，我不会用k8s，kubectl监控1. 看应用资源监控问题。开发问，我的应用CPU/MEM占用情况哪里能看？调试1. 应用调试问题。我怎么重启一下的服务，怎么查看监听的端口？2. 本地调试问题。我的应用要依赖XXX才能调试，我本地怎么访问XXX？访问1. 应用域名问题。我的服务部署上去，域名、IP是什么？2. NodePort端口冲突问题。应用这么多，多个Namespace，NodePort冲突！3. 域名混乱问题。微服务几十个应用，这么多域名，哪个域名是哪个服务的,？权限1. 运行环境权限问题。谁把我的应用重启了？文档1. 设计文档画图问题。2. 1. 设计文件拷来拷去，好麻烦，有没有在线编辑在线协作的，还能画图的沉淀1. 配置构建，手动部署 工作量大，易出错，重复工作，下个项目还得搞一遍；个人技术没法提高，问题一直重现，也没办法沉淀成公司成果，好烦；xxxxxxxxxx 质量低 一些举例 活动质量问题举例代码分支1. 分支管理问题。谁又把没经过测试验证的代码合并进master分支？！测试环境1. 代码管理问题。Test环境的镜像版本能不能和Prod环境保持一致？beta部署1. 生产能不能有一种部署新版本，但是对线上影响小的方式。生产权限1. 生产环境在哪，怎么访问，我需要看生产环境的实时日志xxxxxxxx归纳起来就是，分支管理问题，环境部署问题，环境设计问题。 士气低 加班多效率不高、产出还质量不高；上生产没有信心；上班心情不好啊。 困难二：多业务部门，项目支持问题这个困难，是公司增长到200+人后，领导层进行内部组织架构改革。分五大业务部门。各个业务部门负责独立的年度API。也将 售前、产品经理、BA、前端开发、后端开发、QA等划归到业务部门。 问题来了，分还是合。建平台还是建烟囱？ DevOps建设的系统，之前都是平台化支持全公司的方向来建设的。同时DevOps 工作范围，从底层 云平台、网络、系统、容器、中间件、工具链系统，哪些应该平台化，哪些部门化？ 技术、工具的一点思考技术为业务而生。技术为效率、质量而生。技术也要紧跟新技术浪潮。 针对困难一，回顾来看，主要是通过：技术升级，来解决。 针对困难二，回顾来看，主要是通过：调整团队人员架构、明确职责、技术上改造适配多业务部门制，来解决。 我的工作 - 落地
落地：一段时间，某个技术方向上，进行预研、选型、规划、设计、部署、二次开发，投产、维护 ，持续循环。 当前情况，大数据PaaS还处于初步阶段，应用安全未成型。其余技术已成型，等下一轮技术才需要大幅更新。 容器平台落地–云计算、混合云、容器技术、微服务背景
ToB企业的典型企业网络： 网络互联落地，经过近一年多实践，取得很好的效果。 我们在网络互联方面做了些创造性、巧妙性的工作，取得了事半功倍的效果。 在云计算，公有云背景下，引入了Kubernetes 容器，应用容器的访问是一大效率问题。 解决这个问题，有几个心得： 从业务、应用的角度提需求去设计企业网络。容器网络考虑在内的统一IP地址规划。即Kubernetes的CIDR。容器网络考虑在内的网络互通。开发人员在办公网络里，快速访问容器应用，支持本地调试，业务流量打到办公网络，大幅提高了开发效率。客户网络的互联技术vyos/openV|P|N。客户网络使用的设备千差万别，安全策略千差万别，一种适应性很强的网络技术给大幅提高了我们效率。满足异地协同研发。 应用容器环境设计我们CICD核心实现设计如下，我们部分开源出来 https://github.com/chimeh/cicd-s2e-runner 通过上个章节，各个层次的技术落地。工作汇总如下 技术层次落地工作业务层应用层nacos 容器化，CICD二次开发，自动化，域名自动化，非常强调自动；化、简单性；取好名称PaaS-容器层容器网络规划、rancher部署、私有云RKE，公有云TKE。引入K8S UI（rancher），打通容器网络，支持本地调试PaaS-数据库、中间件层买，库名规范，PaaS大数据层目前相关经验少网络互联层IP地址规划、overlay、underlay网络统一IP规划，打通容器网络、办公网络；CD自动生成ingress 内网、公网域名云平台层买、账号集成，采购流程，权限设计xxxxxxxxxxxxxx落地工作：一段时间，某个技术方向上，进行预研、选型、规划、设计、部署、二次开发，投产、维护 ，持续循环。 业务的技术、员工的技术技术为业务而生，也要紧跟新技术浪潮。 技术承载业务，也助力员工技术成长。 现在回头看，云计算、容器技术、微服务背景下的技术栈升级改造，确实很有必要，具体体现在： 好招人； 近一年面试过程中，候选人还是很认可公司技术栈的。所谓跳槽，看薪资、看平台、看行业、看技术、看薪资。看技术方面取得良好效果。 助力售前项目； 公司积累的 容器、微服务、敏捷开发、CICD、DevOps等技术经验汇总成材料，在去竞标等方面，还是有不少助力； 有效提高了效率、质量，大体降低了成本； 有利岗位忠诚度、岗位满意度； “技术是不是过时了，积累的经验，跳槽是否有帮助？”多数技术岗会有这个问题，直接影响岗位忠诚度与满意度。虽然待遇、薪资无法跟大厂，但是技术栈对员工的技术成长方向是匹配的。 个人回顾，虽然容易感觉“杂”，体系化总结后，我觉得自己还是技术方面成长也是不少； 务实与务虚：项目实施、方法论、团队组织的一点思考 背景、问题、 目标、任务、成果TODO 拿来主义与轮子深刻认知，我们还不是大公司。做之前，先看看有没有轮子。 比如 项目前期，专门进行了DevOps 预研与技术选型； 立足公司实际，结合业界实践，总结公司 DevOps 需求，进行技术选型；包括如阿里 AONE 系统的分支模型、业界实践各大会议 PPT， DevOps 国际峰会（GOIS)、全球运维大会（GOPS）； 理论指导、最佳实践、套路、模板TODO 成果与经验教训TODO 总结TODO |
【本文地址】